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DETAILED ACTION 
Response to Amendment 

1 . This communication is in response to tine Amendment filed 1 9 November 2009. 

2. Claims 1 , 3-1 1 , 1 3, 1 5, 1 6 and 1 9-39 are currently pending. In the Amendment 

filed 19 November 2009, claims 1, 3-8, 10, 13, 15, 16, 21, 23, 25, 26, 30 and 34-37 
have been amended and claims 2, 12, 14, 17 and 18 have been canceled. This action 
is made Final. 

3. The previous prior art rejections of the claims have been withdrawn as 
necessitated by Amendment. 

Information Disclosure Statement 

4. The information disclosure statement (IDS) submitted on 27 January 2010 is in 
compliance with the provisions of 37 CFR 1 .97. Accordingly, the information disclosure 
statement is being considered by the examiner. 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or deschbed as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1, 3-10, 13, 15, 16, 19, 23, 24, 27, 30, 31 and 34-39 are rejected under 
35 U.S.C. 103(a) as being unpatentable over US PGPub 20020120763 to Miloushev 
et al (hereafter Miloushev) in view of US PGPub 2002/0191311 to Ulrich et al 



Application/Control Number: 10/608,037 Page 3 

Art Unit: 2167 

(hereafter Ulrich) in view of US PGPub 20030131104 to Karamanolis et al 
(hereafter Karamanolis). 

Referring to claim 1, Miloushev discloses a file system, comprising: 
a plurality of servers [file servers 101-107] (see [0124] and Fig 1); and 
a master [file switch 100] connected to the servers [file servers 101-107] (see Fig 
1 ) and configured to: 

store namespace data that includes file identifiers for files [namespace 
aggregation] (see [0170]) 

where the master is configured to: 

communicate with the servers at startup of the master to identify files 
stored by the servers (see [0302]). 

While Miloushev discloses the striping of files over a plurality of file servers (see 
[011 8]), Miloushev fails to explicitly disclose that the file servers are stored as chunks. 
Furthermore, while Miloushev discloses a master [file switch] which maintains file 
metadata that can be defined as a data structure containing information about how the 
contents of a given file is stored on the file servers, Miloushev fails to explicitly disclose 
the further limitations of the a master configured to: store mapping data that maps the 
file identifiers to the chunks to which the file identifiers correspond, store an operation 
log that includes a record of changes to at least one of the namespace data or the 
mapping data, and store location data that identifies which of the servers stores which 
of the chunks. Also, while Miloushev discloses the collection of configuration 
information by the file switch during startup of the file switch (see [0302]), Miloushev 
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fails to explicitly disclose the further limitation of where the master is configured to: 
communicate with the servers at startup of the master to identify the chunks stored by 
the servers, and record, in a non-persistent manner, information regarding the chunks 
stored by each of the servers as the location data. 

Ulrich discloses a distributed file system, including the further limitations of 
servers storing files as chunks [blocks] (see [0122]), 

a master connected to the servers and configured to: 

store namespace data that includes file identifiers for files for which the file 
data is stored as chunks [Filename Table 310] (see [0185]; Fig 3; and Fig 14A), 

store mapping data that maps the file identifiers to the chunks to which the 
file identifiers correspond (see [0183]-[0188]; Fig 3; and Fig 14A), 

store location data that identifies which of the servers stores which of the 
chunks [Gee Table 320] (see [0187]; Fig 3; and Fig 14A), 
where the master is configured to: 

communicate with the servers to identify the chunks stored by the servers, 
and record, only in a non-persistent manner [volatile memory], information 
regarding the chunks, which have been identified as being stored by each of the 
servers as the location data (see [0196]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize the metadata disclosed by Ulrich, which stored in a non-persistent 
manner as additional metadata collected by the files system of Miloushev. One would 
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have been motivated to do so since Miloushev stripes data across disks, and 
maintaining metadata of the stripes increases efficiency of the system. 

While the combination of Miloushev and Ulrich (hereafter Miloushev/Ulrich) 
teaches an intent log (Ulrich: see [0039]), Miloushev/Ulrich fails to explicitly disclose the 
further limitation of an operation log that includes a historical record of changes that 
have occurred to at least one of the namespace data or the mapping data. 
Karamanolis discloses a distributed file system (see abstract), including the further 
limitation of an operation log that includes a historical record of changes that have 
occurred to at least one of the namespace data or the mapping data (see [0046]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to store the information disclosed by Karamanolis in the log of Ulrich. One 
would have been motivated to do so in order to increase access speeds of locating data 
through maintenance of location data. 

Referring to claim 3, the combination of Miloushev/Ulrich and Karamanolis 
(hereafter Miloushev/Ulrich/Karamanolis) discloses the system of claim 1, wherein 
where the master is further configured to control placement of new chunks at the 
servers (Miloushev: striping individual files onto a plurality of servers; when a new file is 
to be created, the file switch selects the target file server - see [01 18]; [0182]; [0285]; 
and [0286]; Ulrich: see [0405]-[0407]). 

Referring to claim 4, Miloushev/Ulrich/Karamanolis discloses the system of 
claim 3, wherein where when controlling the placement of new chunks, the master is to: 
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identity one or more of the servers to store tlie new cliunl^s based on at least one 
of utilization of the servers, prior chunk distribution involving the servers, network 
topology, or failure correlation properties associated with the servers (Miloushev: 
utilization of the storage capacity of the file servers and their relative load - see [0383]; 
[0384]; and [0388]; Ulrich: server utilization statistics - see [0137] and [0140]), and 

place the new chunks at the identified one or more servers (Miloushev: switches 
the file create transaction to that server - see [0182]; Ulrich: the blocks are stored in the 
disk array - see [0410]; and Karamanolis: see [0050]). 

Referring to claim 5, Mlloushev/Ulrich/Karamanolis discloses the system of 
claim 1, where the master is further to control redistribution of the chunks stored by the 
servers (Miloushev: a subsystem in the file switch may determine a different way in 
which a given file or set of files should be distributed on the file servers - see [0384]; 
Ulrich: see [0460] - block redistribution). 

Referring to claim 6, Miloushev/Ulrich/Karamanolis discloses the system of 
claim 5, wherein where when controlling redistribution of the chunks, the master is to: 

select a chunk to redistribute based on a current distribution of the chunks, 

identify one or more of the servers to which to move the selected chunk, and 

move the selected chunk to the identified one or more servers [determine a 
different way in which a file or set of files should be distributed on the file servers] 
(Miloushev: determine a different way in which a file or set of files should be distributed 
on the file servers - see [0383]-[0388]; Ulrich: see [0397]-[0404] and [0425]). 



Application/Control Number: 10/608,037 Page 7 

Art Unit: 2167 

Referring to claim 7, Miloushev/Ulrich/Karamanolis discloses the system of 
claim 1 , wherein where the master is further to monitor a state of the servers 
(Miloushev: heartbeat that the file switch periodically sends to the server; state data for 
each file server - see [0191] and [0277]; Ulrich: see [0183]-[0188]). 

Referring to claim 8, Miloushev/Ulrich/Karamanolis discloses the system of 
claim 7, wherein where the master [file switch] is configured to exchange heartbeat 
signals [heartbeat that the file switch periodically sends to the server] with the servers to 
determine the state of the servers [state data for each file server] (Miloushev: see [0191] 
and [0277]). 

Referring to claim 9, Miloushev/Ulrich/Karamanolis discloses the system of 
claim 8, wherein where the heartbeat signals include space utilization information 
(Miloushev: see [0388]; Ulrich: see [0140] and [0507]). 

Referring to claim 10, Miloushev/Ulrich/Karamanolis discloses the system of 
claim 7, wherein where the state of the servers includes information regarding the 
chunks [blocks] stored by the servers (Ulrich: see [0183]-[0188]). 

Referring to claim 13, Miloushev discloses a master [file switch 100] in a file 
system that includes the master connected to a plurality of servers [file servers 101-107] 
(see [0124] and Fig 1), the master comprising: 

means for communicating with the servers at startup of the master to identify files 
stored by the servers (see [0302]). 

While Miloushev discloses the striping of files over a plurality of file servers (see 
[01 18]), Miloushev fails to explicitly disclose that the file servers are stored as chunks. 
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Furthermore, while Miloushev discloses a master [file switch] which maintains file 
metadata that can be defined as a data structure containing information about how the 
contents of a given file is stored on the file servers, Miloushev fails to explicitly disclose 
the further limitations of the a master configured to: store mapping data that maps the 
file identifiers to the chunks to which the file identifiers correspond, store an operation 
log that includes a record of changes to at least one of the namespace data or the 
mapping data, and store location data that identifies which of the servers stores which 
of the chunks. Also, while Miloushev discloses the collection of configuration 
information by the file switch during startup of the file switch (see [0302]), Miloushev 
fails to explicitly disclose the further limitation of means for stohng, in a non-persistent 
manner, location information regarding the chunks stored by each of the servers. 

Ulrich discloses a distributed file system, including the further limitations of 
servers storing files as chunks [blocks] (see [0122]), 

means for storing namespace data that includes file identifiers for files for 

which the file data is stored as chunks [Filename Table 310] (see [0185]; Fig 3; 

and Fig 14A), 

means for storing mapping data that maps the file identifiers to the chunks 
to which the file identifiers correspond (see [0183]-[0188]; Fig 3; and Fig 14A), 

means for storing location data that identifies which of the servers stores 
which of the chunks [Gee Table 320] (see [0187]; Fig 3; and Fig 14A), 

and means for updating location information by periodically instructing the 
servers to identify the data stored by the servers (see [0196]). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize the metadata disclosed by Ulrich, which stored in a non-persistent 
manner as additional metadata collected by the files system of Miloushev. One would 
have been motivated to do so since Miloushev stripes data across disks, and 
maintaining metadata of the stripes increases efficiency of the system. 

While the combination of Miloushev and Ulrich (hereafter Miioushev/Uirich) 
teaches an intent log (Ulrich: see [0039]), Miloushev/Ulrich fails to explicitly disclose the 
further limitation of an operation log that includes a historical record of changes that 
have occurred to at least one of the namespace data or the mapping data. 
Karamanolis discloses a distributed file system (see abstract), including the further 
limitation of an operation log that includes a historical record of changes that have 
occurred to at least one of the namespace data or the mapping data (see [0046]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to store the information disclosed by Karamanolis in the log of Ulrich. One 
would have been motivated to do so in order to increase access speeds of locating data 
through maintenance of location data. It would have been obvious to one of ordinary 
skill in the art at the time of the invention to store the information of Karamanolis in the 
log of Ulrich. One would have been motivated to do so in order to increase access 
speeds of locating data through maintenance of location data. 

Referring to claim 15, Miloushev discloses a file system, comprising: 

a plurality of servers [file servers 101-107] (see [0124] and Fig 1); and 
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a master [file switch 100] connected to the servers [file servers 101-107] (see Fig 
1 ) and configured to: 

store namespace data that includes file identifiers for files [namespace 
aggregation] (see [0170]) 

where the master is configured to: 

communicate with the servers at startup of the master to identify files 
stored by the servers (see [0302]). 

While Miloushev discloses the striping of files over a plurality of file servers (see 
[01 18]), Miloushev fails to explicitly disclose that the file servers are stored as chunks. 
Furthermore, while Miloushev discloses a master [file switch] which maintains file 
metadata that can be defined as a data structure containing information about how the 
contents of a given file is stored on the file servers, Miloushev fails to explicitly disclose 
the further limitations of the a master configured to: store mapping data that maps the 
file identifiers to the chunks to which the file identifiers correspond, store an operation 
log that includes a record of changes to at least one of the namespace data or the 
mapping data, and store location data that identifies which of the servers stores which 
of the chunks. Also, while Miloushev discloses the collection of configuration 
information by the file switch during startup of the file switch (see [0302]), Miloushev 
fails to explicitly disclose the further limitation of where the master is configured to: 
determine location information by communicating with the servers, the location 
information being based on which of the servers store ones of the chunks, store the 
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location infornnation as the location data, and update the location data by periodically 
communicating with the servers to obtain changes to the location data. 

Ulrich discloses a distributed file system, including the further limitations of 
servers storing files as chunks [blocks] (see [0122]), 
a master connected to the servers to: 

store namespace data that includes file identifiers for files for which the file 
data is stored as chunks [Filename Table 310] (see [0185]; Fig 3; and Fig 14A), 

store mapping data that maps the file identifiers to the chunks to which the 
file identifiers correspond (see [0183]-[0188]; Fig 3; and Fig 14A), 

store location data that identifies which of the servers stores which of the 
chunks [Gee Table 320] (see [0187]; Fig 3; and Fig 14A), 
where the master is configured to: 

determine location information by communicating with the servers, the 
location information being based on which of the servers store ones of the 
chunks, store the location information as the location data, and update the 
location data by periodically communicating with the servers to obtain changes to 
the location data (see [0196]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize the metadata disclosed by Ulrich, which stored in a non-persistent 
manner as additional metadata collected by the files system of Miloushev. One would 
have been motivated to do so since Miloushev stripes data across disks, and 
maintaining metadata of the stripes increases efficiency of the system. 
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While tine combination of Milousliev and Ulrich (hereafter Miloushev/Ulrich) 
teaches an intent log (Ulrich: see [0039]), Miloushev/Ulrich fails to explicitly disclose the 
further limitation of an operation log that includes a historical record of changes that 
have occurred to at least one of the namespace data or the mapping data. 
Karamanolis discloses a distributed file system (see abstract), including the further 
limitation of an operation log that includes a historical record of changes that have 
occurred to at least one of the namespace data or the mapping data (see [0046]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to store the information disclosed by Karamanolis in the log of Ulrich. One 
would have been motivated to do so in order to increase access speeds of locating data 
through maintenance of location data. 

Referring to claim 16, Miloushev discloses a file system, comprising: 
a plurality of servers [file servers 101-107] (see [0124] and Fig 1); and 
a master [file switch 100] connected to the servers [file servers 101-107] (see Fig 
1 ) and configured to: 

store namespace data that includes file identifiers for files [namespace 
aggregation] (see [0170]) 

where the master is configured to: 

communicate with the servers at startup of the master to identify files 
stored by the servers (see [0302]). 

While Miloushev discloses the striping of files over a plurality of file servers (see 
[01 18]), Miloushev fails to explicitly disclose that the file servers are stored as chunks. 
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Furthermore, while Miloushev discloses a master [file switch] which maintains file 
metadata that can be defined as a data structure containing information about how the 
contents of a given file is stored on the file servers, Miloushev fails to explicitly disclose 
the further limitations of the a master configured to: store mapping data that maps the 
file identifiers to the chunks to which the file identifiers correspond, store an operation 
log that includes a record of changes to at least one of the namespace data or the 
mapping data, and store location data that identifies which of the servers stores which 
of the chunks. Also, while Miloushev discloses the collection of configuration 
information by the file switch during startup of the file switch (see [0302]), Miloushev 
fails to explicitly disclose the further limitation of where the master is configured to: 
communicate with the servers to determine location information of the data, the location 
information being based on which of the servers store the chunks, and store the location 
information as the location data. 

Ulrich discloses a distributed file system, including the further limitations of 
servers storing files as chunks [blocks] (see [0122]), 

a master connected to the servers and configured to: 

store namespace data that includes file identifiers for files for which the file 

data is stored as chunks [Filename Table 310] (see [0185]; Fig 3; and Fig 14A), 
store mapping data that maps the file identifiers to the chunks to which the 

file identifiers correspond (see [0183]-[0188]; Fig 3; and Fig 14A), 

store location data that identifies which of the servers stores which of the 

chunks [Gee Table 320] (see [0187]; Fig 3; and Fig 14A), 
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where the master is configured to: 

communicate with the servers to determine location information of the data, the 
location information being based on which of the servers store the chunks, and store the 
location information as the location data (see [0196]). 

It would have been obvious to one of ordinary skill In the art at the time of the 
invention to utilize the metadata disclosed by Ulrich, which stored in a non-persistent 
manner as additional metadata collected by the files system of Miloushev. One would 
have been motivated to do so since Miloushev stripes data across disks, and 
maintaining metadata of the stripes increases efficiency of the system. 

While the combination of Miloushev and Ulrich (hereafter Miloushev/Ulrich) 
teaches an intent log (Ulrich: see [0039]), Miloushev/Ulrich fails to explicitly disclose the 
further limitation of an operation log that includes a historical record of changes that 
have occurred to at least one of the namespace data or the mapping data. 
Karamanolis discloses a distributed file system (see abstract). Including the further 
limitation of an operation log that includes a historical record of changes that have 
occurred to at least one of the namespace data or the mapping data (see [0046]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to store the information disclosed by Karamanolis in the log of Ulrich. One 
would have been motivated to do so in order to increase access speeds of locating data 
through maintenance of location data. 
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Referring to claim 19, Miloushev/Ulrich/Karamanolis discloses the file system of 
claim 1 , where the file identifiers are organized hierarchically in a tree of directories 
(Miloushev: see [0179] and [0389]; Ulrich: see [0184]). 

Referring to claim 23, Miloushev/Ulrich/Karamanolis discloses the file system of 
claim 1, where the master is to update the location data by periodically instructing the 
servers to provide information [polling] regarding the chunks stored by the servers 
(Ulrich: see [0113]; [0131]; and [0183]-[0187]). 

Referring to claim 24, Miloushev/Ulrich/Karamanolis discloses the file system of 
claim 1 , where the operation log includes a logical timeline that defines an order for 
concurrent operations (Karamanolis: see [0046]). 

Referring to claim 27, Miloushev/Ulrich/Karamanolis discloses the master of 
claim 13, where the operation log includes a logical timeline that defines an order for 
concurrent operations (Karamanolis: see [0046]). 

Referring to claim 30, Miloushev discloses a method performed by a master 
device [file switch 100] in a file system that includes the master device connected to a 
plurality of server devices [file servers 101-107] (see [0124] and Fig 1), the method 
comprising: 

communicating with the server devices to identify files stored by the servers (see 
[0302]); and 

storing namespace data that includes file identifiers for files [namespace 
aggregation] (see [0170]). 
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While Miloushev discloses the striping of files over a plurality of file servers (see 
[01 1 8]), Miloushev fails to explicitly disclose that the file servers are stored as chunks. 
Furthermore, while Miloushev discloses a master [file switch] which maintains file 
metadata that can be defined as a data structure containing information about how the 
contents of a given file is stored on the file servers, Miloushev fails to explicitly disclose 
the further limitations of storing location data that identifies which of the servers stores 
which of the chunks; storing mapping data that maps the file identifiers to the chunks to 
which the file identifiers correspond, maintaining an operation log that includes a record 
of changes to at least one of the namespace data and the mapping data. Ulrich 
discloses a distributed file system, including the further limitations of servers storing files 
as chunks [blocks] (see [0122]), 

storing namespace data that includes file identifiers for files for which the file data 
is stored as chunks [Filename Table 310] (see [0185]; Fig 3; and Fig 14A), 

storing mapping data that maps the file identifiers to the chunks to which the file 
identifiers correspond (see [0183]-[0188]; Fig 3; and Fig 14A), 

storing, in a non-persistent manner and based on communicating with the server 
devices location data that identifies which of the servers stores which of the chunks 
[Gee Table 320] (see [0187]; Fig 3; and Fig 14A), 

communicating with the servers to identify the chunks stored by the servers (see 
[0196]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize the metadata disclosed by Ulrich, which stored in a non-persistent 
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manner as additional metadata collected by the files system of Miloushev. One would 
have been motivated to do so since Miloushev stripes data across disks, and 
maintaining metadata of the stripes increases efficiency of the system. 

While the combination of Miloushev and Ulrich (hereafter Miloushev/Ulrich) 
teaches an intent log (Ulrich: see [0039]), Miloushev/Ulrich fails to explicitly disclose the 
further limitation of an operation log that includes a historical record of changes that 
have occurred to at least one of the namespace data or the mapping data. 
Karamanolis discloses a distributed file system (see abstract), including the further 
limitation of an operation log that includes a historical record of changes that have 
occurred to at least one of the namespace data or the mapping data (see [0046]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to store the information disclosed by Karamanolis in the log of Ulrich. One 
would have been motivated to do so in order to increase access speeds of locating data 
through maintenance of location data. 

Referring to claim 31, Miloushev/Ulrich/Karamanolis discloses the method of 
claim 30, where the operation log includes a logical timeline that defines an order for 
concurrent operations (Karamanolis: see [0046]). 

Referring to claim 34, Miloushev/Ulrich/Karamanolis discloses the file system of 
claim 15, where the master is further configured to: identify one or more of the servers 
to store a new chunk based on prior chunk distribution involving the servers, and place 
the new chunk at the identified one or more servers (Miloushev: see [0190]; Ulrich: see 
Fig 24A). 
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Referring to claim 35, Miloushev/Ulrich/Karamanolis discloses the file system of 
claim 15, where the master is further to: identify one or more of the servers to store a 
new chunk based on failure correlation properties associated with the servers, and 
place the new chunk at the identified one or more servers (Miloushev: see [0190]; 
Ulrich: see Fig 24A and [0507]). 

Referring to claim 36, Miloushev/Ulrich/Karamanolis discloses the file system of 
claim 16, where the master is to: identify one or more of the servers to store a new 
chunk based on prior chunk distribution involving the servers, and place the new chunk 
at the identified one or more servers (Miloushev: see [0190]; Ulrich: see Fig 24A). 

Referring to claim 37, Miloushev/Ulrich/Karamanolis discloses the file system of 
claim 16, where the master is further configured to: identify one or more of the servers 
to store a new chunk based on failure correlation properties associated with the servers, 
and place the new chunk at the identified one or more servers (Miloushev: see [0190]; 
Ulrich: see Fig 24A and [0507]). 

Referring to claim 38, Miloushev/Ulrich/Karamanolis discloses the master of 
claim 13, further comprising: means for identifying one or more of the servers to store a 
new chunk based on utilization of the servers, prior chunk distribution involving the 
servers, and failure correlation properties associated with the servers; and means for 
placing the new chunk at the identified one or more servers (Miloushev: see [0190]; 
Ulrich: see Fig 24A and [0507]). 

Referring to claim 39, Miloushev/Ulrich/Karamanolis discloses the method of 
claim 30, further comprising: identifying one or more of the server devices to store a 
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new chunk based on utilization of the server devices, prior chunk distribution involving 
the server devices, and failure correlation properties associated with the server devices; 
and placing the new chunk at the identified one or more server devices (Miloushev: see 
[0190]; Ulrich: see Fig 24A and [0507]). 

7. Claims 11, 21 and 22 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over US PGPub 20020120763 to Miloushev et al in view of US 
PGPub 2002/0191311 to Ulrich et al in view of US PGPub 2003/0131104 to 
Karamanolis et al as applied to claims 1 and 10 above, and further in view of US 
Patent No 5,644,751 to Burnett (hereafter Burnett). 

Referring to claim 11, Miloushev/Ulrich/Karamanolis fail to explicitly disclose the 
further limitation of where the information of claim 10 includes version numbers of the 
chunks. Burnett discloses a distributed file system, Including the further limitation of 
where the Information includes version numbers of the chunks (see column 8, lines 35- 
54). 

It would have been obvious at the time of the invention to utilize the information 

disclosed by Burnett with the system of Mlloushev/Ulhch/Karamanolls. One would have 
been motivated to do so in order to increase the efficiency of the system by maintaining 
version Information. 

Referring to claim 21, Miloushev/Ulrich/Karamanolis fail to explicitly disclose the 
further limitation of where the master is configured to identify one of the chunks via a 
chunk handle that uniquely identifies the one of the chunks. Burnett discloses a 
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distributed file system, including the further limitation of where the master is configured 
to identify one of the chunks via a chunk handle that uniquely identifies the one of the 
chunks (see column 8, lines 35-54). 

It would have been obvious at the time of the invention to utilize the information 
disclosed by Burnett with the system of Miloushev/Ulrich/Karamanolis. One would have 
been motivated to do so in order to increase the efficiency of the system by maintaining 
version information. 

Referring to claim 22, the combination of Miloushev/Ulrich/Karamanolis and 
Burnett discloses the file system of claim 21 , where the chunk handle encodes a 
timestamp (Burnett: see column 8, lines 35-54). 

8. Claim 20 is rejected under 35 U.S.C. 103(a) as being unpatentable over US 
PGPub 20020120763 to Miloushev et a! in view of US PGPub 2002/0191311 to 
Ulrich et a! in view of US PGPub 2003/0131104 to Karamanolis et a! as applied to 
claim 1 above, and further in view of US Patent No 5,283,894 to Deran (hereafter 
Deran). 

Referring to claim 20, while Miloushev/Ulrich/Karamanolis discloses a tree of 
directories, Miloushev/Ulrich/Karamanolis fails to explicitly disclose the further limitation 
of where the master stores the namespace data using prefix-compression. Deran 
discloses the further limitation of applying prefix-compression to a tree (see column 22, 
lines 27-41). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize the prefix-compression algorithm disclosed by Deran with the 
disclosed directory tree. One would have been motivated to do so since a directory can 
include a plurality of entries and prefix compression allows for increasing access speed 
of the directory. 

9. Claims 25, 26, 28, 29, 32 and 33 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over US PGPub 20020120763 to Miloushev et al in view of US 
PGPub 2002/0191311 to Ulrlch et al in view of US PGPub 2003/0131104 to 
Karamanolis et al as applied to claim 1 above, and further in view of US Patent No 
6,021,408 to Burnett (hereafter Burnett). 

Referring to claims 25, 28 and 32, while Miloushev/Ulrich/Karamanolis 
discloses a log, fails to explicitly disclose the further limitation of where the master is 
configured to: determine when a size of the operation log exceeds a threshold, and 
create a checkpoint of the operation log when the size of the operation log exceeds the 
threshold. Ledain et al discloses migration in a distributed system, including the further 
limitation of determine when a size of the operation log exceeds a threshold, and create 
a checkpoint of the operation log when the size of the operation log exceeds the 
threshold (see column 9, line 62 - column 10, line 34; column 21, lines 22-36; column 
25, line 57 - column 26, line 9; and column 29, line 58 - column 30, line 6). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to apply the steps disclosed by Ledain for maintaining a log to the log of 
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Miloushev/Ulrich/Karamanolis. One would have been motivated to do so in order to 
decrease the recovery time by decreasing the size of the log. 

Referring to claims 26, 29 and 33, the combination of 
Miloushev/Ulrich/Karamanolis and Ledain discloses the file system of claim 25, where 
the master is configured to: create a new operation log file, and create the checkpoint 
as a background operation (Ledain: see column 9, line 62 - column 10, line 34; column 
21 , lines 22-36; column 25, line 57 - column 26, line 9; and column 29, line 58 - column 
30, line 6). 

Response to Arguments 

1 0. Applicant's arguments on pages 1 3-1 6 of the Remarks which states "... do not 
disclose or suggest a master that is to, among other things, store an operation log that 
includes a historical record of changes that have occurred to at least one of namespace 
data ..." been considered but are moot in view of the new ground(s) of rejection. 

1 1 . Referring to Applicant's argument on pages 1 6-1 7 of the Remarks which states 
"... Applicants submit that Ulrich et al does not disclose or suggest a master that is to, 
among other things, communicate with the servers at startup of the master to identify 
the chunks stored by the servers the examiner respectfully disagrees. It is noted 
that the examiner states that Miloushev teaches the concept of communicating with the 
servers at startup of the master to identify files stored by the servers in paragraph 
[0302]. Miloushev states "The file switches exchange such configuration information 
during their startup ..." Ulrich teaches storing the tables in volatile memory. Volatile 
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memory is memory that stores data until tlie system loses power. This concept is 
analogous to storing data in a non-persistent manner. 

1 2. In regards to Applicant's argument on page 1 8 of the Remarks which states 
"Applicants submit that the examiner has failed to establish a prima facie case of 
obviousness," the examiner respectfully disagrees. Miloushev has the ability to collect 
and store metadata. Therefore, since Miloushev is configured to already collect 
metadata, it would be possible for Miloushev to also collect further metadata. 
Furthermore, the concept data in either volatile or non-volatile memory is well-known in 
the art. Therefore, it is merely design for utilizing one method over another. 

13. Regarding the Applicant's argument on page 19 which states "Furthermore, the 
Examiner's reason does not explain why it would have been obvious to record 
information regarding where chunks are stored in a non-persistent manner," the 
examiner respectfully disagrees. This particular information is considered to be the 
metadata. 

14. Applicant's arguments with respect to claim 4 on page 20 of the Remarks have 
been considered but are moot in view of the new ground(s) of rejection. 

1 5. In regards to the arguments on pages 21 -24, the rejections are maintained for 
the reasons stated above. 

Conclusion 

16. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 
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A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 
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Contact Information 

Any inquiry concerning tliis communication or earlier communications from tine 
examiner sliould be directed to KIMBERLY LOVEL wliose teleplione number is 
(571 )272-2750. The examiner can normally be reached on 9:00 - 5:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Cottingham can be reached on (571) 272-7079. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 
273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status Information for unpublished applications Is available through Private PAIR only. 
For more Information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/John R. Cottingham/ Klmberly Lovel 

Supervisory Patent Examiner, Art Unit 21 67 Examiner 

Art Unit 2167 

IKU 

27 February 2010 
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